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(g) Database system. 

@ A system is provided for managing database 
connections between concunrent user appli- 
cations 94 and a plurality of databases 82 in a 
database processing system, whilst minimizing 
the number of connections made to a database 
by allowing such connections to be shared by 
multiple applications. Shared and exclusive 
connections are provided and. depending on 
the user application, a connection manager 80 
automatically routes a database access request 
through either an existing shared connection or 
an exclusive connection. A database access 
object 84, 90 is introduced that includes two 
types of methods for connecting to a specified 
database in two different simultaneous paths. 
First, a shared connection through a catalog 
server process is made to process schema 
query requests for definition retrieval. Sec- 
ondly, another connection is made to retrieve 
and manipulate data from the database respon- 
sive to SQL execution requests. The SQL execu- 
tion path itself may be either exclusive or 
shared with other associated database access 
objects requesting SQL execution in the same 
database. 
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The present invention relates to a database proc- 
essing system of the type having a plurality of data- 
bases and a plurality of user applications for process- 
ing database access requests. 

In a data processing system complex servicing 
many databases and many concurrent users, a user 
application (UA) demands access to a specified da- 
tabase by issuing a database access request. Such 
requests may include, for instance* simple catalog 
lookup requests, herein denominated as database 
"schema queries", or transactions and combinations 
of transactions, herein denominated "units of work" 
(UOWs) that operate to both read and change speci- 
fied records in the database. 

The state of the art and data processing systems 
supporting multiple concurrent processes can be ap- 
preciated with reference to, for instance, An Introduc- 
tion to Operating Systems , Harvey M. Deitel, 2nd ed., 
Addison-Wesley Publishing Company. Inc.. 1990, 
(N.B., Ch. 3, "Process Concepts"). Also, reference is 
made to Computer Architecture Parallel Processing , 
Kai Hwang, at al., McGraw-Hill, Inc., 1984 (N.B,. Ch. 
8 "Multiprocessing Control and Algorithms") and The 
Design of the UNIX Operating System, Maurice J. 
Bach, Prentice-Hall. Inc.. 1986 (N.B.. Ch. 7 "Process 
Control" and Ch, 12 "Multiprocessor Systems"). 

Whenever a UA requests access to a particular 
database, a "connection" step is necessary to permit 
the corresponding Data Base Management System 
(DBMS) to allocate processing resources for servic- 
ing the database access request. Because a DBMS 
may not generally support multiple active connec- 
tions to a specified database (e.g.. DB2 for OS/2), 
overall system performance may deteriorate when a 
UA requires either (a) support for concurrent access 
to many databases, or (b) support for multiple connec- 
tions to a specified database. 

For example, if the UA must display information 
from different databases, responsive to user input, 
the UA may need to connect, access and disconnect 
from many different databases at various times. Also, 
if the UA is managing many different reports derived 
from the same database, several concurrent connec- 
tions to that same database may be useful for optim- 
izing reporting efficiency. Even where the DBMS sup- 
ports multiple concurrent active connections, the pro- 
cedure for establishing each such connection con- 
sumes substantial processor resources, especially if 
the database to be connected is a remote database. 
For instance. DB2 for OS/2 does not support multiple 
active connections to a specified database within a 
single process, requiring the spawning of multiple 
server processes to accomplish this. 

Although th r connection overhead burden is 
not a major problem in traditional database systems 
wherein UAs work with a single database, modern cli- 
ent/server environments introduce generalized client 
database user applications that support multiple da- 



tabase servers, requiring many concurrent accesses 
to different databases. One solution available for op- 
erating systems that support multiple processes is to 
spawn a new server process for each new database 

5 connection for UAs requiring multiple active databas 
connections. The new server process handles all in- 
teraction for that particular connection between the 
UA and the database of interest and the UAs main 
process continues to service the user interface and 

10 display. Although this arrangement permits the UA to 
maintain multiple active connections to a single data- 
base, it does nothing to alleviate the significant proc- 
essing overhead required to maintain each new con- 
nection and actually adds an additional performance 

15 burden for spawning each new process. 

Accordingly, the invention provides a method of 
operating a database processing system having a 
plurality of databases, a plurality of user applications 
(UAs) for processing database access requests in- 

20 eluding schema queries and standard query lan- 
guage (SQL) units of work (UoWs). and a plurality of 
database access (DBA) objects for passing messag- 
es between said UAs and said databases, said meth- 
od providing access to data in a first database respon- 

25 sive to one or more database access requests from 
a first UA, said method comprising the steps of: 

sending a database access request from the 
first UA to a first DBA object for passing messages be- 
tween said first UA and said first database, said first 

30 DBA object including first schema retrieval methods 
and first SQL execution methods; 

transferring schema query messages be- 
tween said first schema retrieval methods of said first 
DBA object and said first database through a first log- 

35 ical path; and 

transferring SQL UOW execution messages 
between said first SQL execution methods of said 
first DBAobject and said first database through a sec- 
ond logical path. 

40 In a preferred embodiment, said first transferring 

step comprises the steps of: if not already existent, 
spawning a first catalog server process for retrieving 
data from said first database; and connecting said 
first DBA object to said first catalog server process. 

45 Said connecting step comprises the steps of: if not al- 
ready existent, constructing a first named pipe object 
for transferring messages to and from said first cata- 
log server process; and linking said first named pipe 
object to said first DBA object Said first logical path 

50 is shared among a plurality of said DBA objects by 
logically re-linking said first named pipe object to a 
DBA object responsive to a schema query message 
from that DBA object Thus, if said first named pipe 
object is linked to a second DBAobject. the method 

55 further comprises the steps of completing a schema 
query message transfer between said second DBA 
object and said first database; and disconnecting said 
first named pipe object from said second DBAobject, 
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in order to allow re-linking to another DBA object. 

In a further preferred embodiment, the second 
transferring step comprises the steps ot if not already 
existent, spawning a first SQL server process for exe- 
cuting UOWs in said first database; and connecting 
said first DBAobjectto said first SQLServer process. 
Said connecting step comprises the steps of: if not al- 
ready existent, constructing a second named pipe ot>- 
ject for transferring messages to and from said first 
SQL server process: and linking said second named 
pipe object to said first DBA object Said plurality of 
DBA objects includes a plurality of exclusive DBA ob- 
jects and a plurality of associated DBA objects; and 
said second logical path is shared among a plurality 
of said associated DBA objects by logically re-linking 
said second named pipe object to an associated DBA 
object responsive to a SQL UOW message from that 
associated DBA object. Thus, If said second named 
pipe object is linked to a second DBAobject, the meth- 
od further comprises the steps of completing the 
transfer of a UOW execution message between said 
second DBA object and said first database; and dis- 
connecting said second named pipe object from said 
second DBA object, in order to allow re-linking to an- 
other DBA object. 

It is also preferred that said database processing 
system includes a plurality of said DBA objects cou- 
pled to a plurality of said databases through a plurality 
of said first and second logical paths; and at least one 
said second logical path is shared by a plurality of 
said DBA objects. 

The invention also provides a database process- 
ing system including a plurality of objects and a plur- 
ality of databases, said objects including a plurality of 
us r applications (UAs) that make database access 
r quests for processing schema queries and stan- 
dard query language (SQL) unit of work (UOW) exe- 
cutions, said system comprising: 

a plurality of database access (DBA) objects 
for receiving said database access requests for one 
database from one UA and having methods for ex- 
changing schema retrieval messages with said one 
database over a first logical path and methods for ex- 
changing SQL UOW execution messages with said 
one database over a second logical path; 

a plurality of catalog server processes, each 
linked to one database, for processing said schema 
queries responsive to messages exchanged with said 
DBA objects; 

a plurality of SQL server processes, each 
linked to one database, for processing said SQL exe- 
cution requests responsive to messages exchanged 
with said DBA objects; and 

connection manager means for selecting and 
linking a catalog server process to a DBA object to 
form a first logical path and for selecting and linking 
a SQL server process to a DBA object to form a sec- 
ond logical path. 



In a preferred embodiment, each database is 
linked to one catalog server process that is shared by 
all DBA objects linked to that database. Said plurality 
of DBA objects includes: associated DBA objects, 
5 each having methods for exchanging said SQL UOW 
execution request messages with a SQL server proc- 
ess over a second logical path shared with other as- 
sociated DBA objects; and exclusive DBA objects, 
each having methods for exchanging said SQL UOW 
10 execution request messages with a SQL server proc- 
ess over an exclusive second logical path that is un- 
available to other DBA objects. Said plurality of SQL 
server processes includes: one or more exclusive 
SQL server processes each linked to no more than 
15 one exclusive DBA object; and one or more shared 
SQL server processes, each available for linkage to 
any of a plurality of said associated DBAobjects. Said 
connection manager means includes: exclusive link 
means for linking an exclusive SQL server process to 
20 one exclusive DBA object to form an exclusive second 
logical path; shared link means for linking a shared 
SQL server process to one associated DBA object to 
form another second logical path; and switching 
means for disconnecting a shared SQL server proc- 
25 ess from a first associated DBA object and for re-link- 
ing said shared SQL server process to a second as- 
sociated DBA object. Said switching means includes 
database connection table (DBCT) means for speci- 
fying the number of DBA objects shared by each said 
30 shared SQL server process. 

The above approach provides a shared database 
connection process in a client-server system environ- 
ment. A Database Access (DBA) object allows em- 
bedded class methods for separately but concurrent- 
35 ly supporting both schema retrieval and Standard 
Query Language (SQL) execution requests. Two 
types of servers executing in separate processes 
service the DBA object One of these types can be 
shared between concurrent DBA objects. Depending 
40 on the DBA class method, the necessary linkage to a 
database may be assembled under the control of a 
Connection Manager (CM), which refers to a Data 
Base Connection Table (DBCT) maintained in mem- 
ory to track the creation and sharing of all such server 
45 processes. 

This approach helps to minimize the necessary 
number of database connections created in a multiple 
user environment, and user application (UA) connec- 
tions to databases can be shared by many concurrent 
50 UAs, whilst exclusive database connections are 
available for SQL execution requests requiring data- 
base updates and modification. 

A shared connection can be used to read data- 
base schema information that does not result in mod- 
55 if ication of the database. Shared database connec- 
tions may also be used to process SQL execution re- 
quests that modify the database when so requested 
by the UA client. 
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In a preferred embodiment, the exclusive server 
process has a dedicated connection to a specific da- 
tabase and a dedicated connection to a DBA object 
which is sponsored by a single UA. The shared server 
process has a dedicated connection to a specific da- 5 
tabase and is available for connection upon demand 
to any number of DBA objects when such DBAobjects 
have permission to share such server process from 
a single sponsoring UA, A special shared server proc- 
ess ("catalog server process") for schema retrieval is io 
provided which has a dedicated connection to a spe- 
cific database and is available for connection to any 
DBA object responsive to schema retrieval requests 
only. Thus advantageously a single shared schema 
server process is sufficient for each database. is 

Thus a database server system manages access 
requests from concurrent user application programs. 
An efficient database connection management sys- 
tem employs shared connection objects each for con- 
current connection of a plurality of user applications 20 
to a single database. Such an approach allows multi- 
ple concurrent active connections to be maintained 
between a single or multiple databases and a user ap- 
plication without incurring new process and connec- 
tion creation processing overhead responsive to ev- 25 
ery database access request. 

An embodiment of the invention will now be de- 
scribed in detail by way of example only with refer- 
ence to the following drawings: 

Fig. 1 is a functional block diagram of a database 30 
processing system in accordance with the pres- 
ent invention; 

Fig. 2 is a functional block diagram illustrating the 
data access subcomponents for use in the sys- 
tem of Figure 1 ; ^5 
Fig. 3 is a functional block diagram illustrating an 
alternative process model for a database proc- 
essing system; 

Fig. 4 is afunctional block diagram illustrating a 
database connection table (DBCT); 40 
Fig. 5 is a functional block diagram of a database 
processing system in accordance with the pres- 
ent invention; and 

Fig. 6 is a functional block diagram illustrating the 
SQL UOW execution message and data flow. 45 
Fig. .1 shows an example of a process model pro- 
viding concurrent access to multiple databases in a 
database processing system. The model in Fig. 1 in- 
cludes a plurality of objects, which are known in the 
art to comprise a data structure definition and its de- so 
fined procedures in a single structure. Objects are in- 
stances of a "class", each instance having its own pri- 
vate instance variables. The "class definition" defines 
the properties of the object in that class. The proce- 
dures embedded in an object (also denominated 55 
"methods") are activated by "messages" sent to the 
object by another object Thus, as is well-known in the 
art, the basic control structure in an object-oriented 



programming system exemplified by the process 
structure of Fig. 1 is message passing. Both data and 
processing requirements are embedded in the class 
definition of an object and the processing is accom- 
plished through message exchanges between ob- 
jects. 

Accordingly, each of the objects and processes 
shown in Fig. 1 are physically contained in a data stor- 
age means within a computer processing system. 

Fig. 1 shows a plurality of Database Access 
(DBA) objects, exemplified by the exclusive DBA ob- 
ject 10 for database D1 in process A and the exclusive 
DBA object 12 for the database D2 in process C. Also 
shown are "associated" DBA objects exemplified by 
DBAobjects 14 and 16 for database D1 in process B. 
For exemplary purposes only. DBAobjects 10 and 12 
belong to two different processes and DBAobjects 14 
and 16 are shown together with a plurality of other 
such DBAobjects in one process 18. 

The DBA object provides a plurality of "methods" 
to support schema retrieval and execution of Stan- 
dard Query Language (SQL) Units Of Work (UoWs). 
When a User Application (UA) requires access to a 
specific database, the UA either creates a DBA object 
associating it with the specific database or uses such 
DBA object created earlier. With the DBA object, the 
UAmay then access the specific database using the 
methods embedded in the DBA object, which are ser- 
viced by the servers executing in separate process- 
es. 

For example, consider DBA object 10 in Fig. 1. 
DBA object 10 names database D1 and includes em- 
bedded schema retrieval methods 20 for accessing 
database D1 to retrieve catalog information. DBA ob- 
ject 10 also includes embedded SQL execution meth- 
ods 22 for servicing SQL UOW executions. In Fig. 1, 
SQL service methods 22 is denominated "exclusive" 
SQL execution methods, which herein denotes that 
DBA object 10 requires access to database D1 
through an exclusive server process that is not 
shared with any other DBA object All other DBA ob- 
jects shown in Fig. 1 also contain catalog service 
methods and SQL service methods embedded within 
the class. However, these other DBA objects, exem- 
plified by DBA object 14, may contain "shared" SQL 
service methods, exemplified by shared SQL execu- 
tion methods 24 in DBA object 14. Methods 24 permit 
DBA object 14 to share a SQL server process with 
other "associated" DBAobjects, such as DBA object 
16, to access a single database (D1). 

Thus, requests from associated DBAobjects 14 
and 16 are serviced by either of two types of server 
processes, embodied as the shared SQL server proc- 
ess 26 and th catalog server process 28. Note that, 
for instance, DBA object 14 simultaneously forwards 
schema query messages to database D1 from cata- 
log service methods 30 through catalog server proc- 
ess 28 and executes SQL UOWs in database D1 from 
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shared SQL service methods 24 through shared SQL 
server process 26. Each DBA access object employs 
concurrent methods for (a) reading schema informa- 
tion such as database catalog tables and columns 
and (b) executing SQL UOWs to retrieve and manip- 
ulate data from the database. These concurrent 
methods operate with separate concurrent process- 
s, exemplified by processes 26 and 28. 

The several types of server processes shown in 
Fig. 1 are now discussed. The exclusive SQL server 
process, exemplified by processes 32 and 34 is cou- 
pled to a specific database (D1 ) for the exclusive use 
of the client DBA object. Exclusive SQL server proc- 
esses 32 and 34 each have dedicated connections to 
database D1. The exclusive SQL server process 36 
has a dedicated connection to database D2. All such 
exclusive SQLServer processes also have dedicated 
connections to their client DBA object, substantially 
as shown. 

The shared SQL server processes 26 and 38 and 
the catalog server processes 28 and 40 also have 
dedicated connections to the specified database but 
each may be shared by a plurality of DBA objects re- 
quiring access to the specified database. Thus, for in- 
stance, catalog server process 28 has a single dedi- 
cated connection to database D1 that is shared 
among four DBA object clients. In fact, only one cat- 
alog server process is required for each underlying 
database, which is then shared by all DBA objects re- 
quiring schema retrieval from the database, because 
no changes are made to the database. For SQL exe- 
cution requests, the system provides the UAwith the 
option of specifying either a shared server or an ex- 
clusive server. The UA implements this specification 
by creating a new DBA object or calling an existing 
DBA object for database access through an exclusive 
SQL server process or by creating or calling a DBA 
object for accessing the database through a shared 
SQL server process. 

The UA specification decision raises several im- 
plications. For instance, an exclusive SQL server 
process offers a dedicated DBA object connection to 
the database for SQL UOW execution only, relying on 
a shared catalog server process for schema retrieval. 
This avoids any interference with transactions from 
other DBA objects when issuing a transaction com- 
mit/rollback. Specifying the appropriate DBA object 
having methods for connecting to an exclusive SQL 
server eliminates any possible wait for access to the 
SQL server process and also eliminates possibility of 
deadlocks. However, specifying another DBA object 
with methods for connecting to an exclusive SQL ser- 
ver creates an additional connection to the database, 
with attendant system overhead. 

Specifying a shared SQL server process avoids 
proliferation of connections to the database for SQL 
UOW executions. However, to avoid interference with 
transactions from other DBA objects during com- 



mit/rollback of a transaction, the U A must explicitly is- 
sue demarcation calls around every UOW to ensure 
serialization. Internally, the DBA object uses start- 
TransactionO and endTransaction() messages to de- 

5 mark UOW boundaries and ensure serialization of 
transactions and transaction groups in the shared 
SQL server process! The advantage of specifying a 
shared SQL server process is the minimization of 
system database connection overhead. The disad- 

10 vantage of using DBA objects with shared server ac- 
cess methods, such as objects 14 and 16 in Fig. 1 , is 
the possibility of deadlocking in cases where UAs do 
not properly mark UOW boundaries and the possibil- 
ity of waiting for access to the shared SQL server 

15 process. 

An exclusive SQL server process is spawned the 
first time a client UA invokes a method in a DBA object 
that requires exclusive SQL processing. Thus, there 
can exist as many as one such exclusive SQL process 

20 for each client DBA object in the system. This also 
means that the UA may choose to use a separate ex- 
clusive SQL server process for each thread or may 
use a single exclusive SQL server process for multi- 
ple threads by manipulating the data routing among 

25 the threads. Parenthetically, the UAmay also define 
a single UOW as including a plurality of SQL process- 
ing requests or transactions. 

A shared SQL server process is spawned when 
the first UA invokes a SQL execution request in a DBA 

30 object that requires shared SQL processing. All client 
UA processes or threads for a specified database 
then process all SQL execution requests through the 
same shared SQL server process by way of the cor- 
responding client DBA objects. The client UA must 

35 now demark the beginning and end of each transac- 
tion or UOW before submitting an SQL execution re- 
quest to any of the DBAobjects to ensure serialization 
of concunrent UOWs at the shared SQL server proc- 
ess. 

40 Only one catalog server process is necessary for 

each specified database because all UA processes 
and threads can conrumunicate with the specified da- 
tabase through a single shared catalog server proc- 
ess for catalog lookup requests. The catalog server 

45 process is spawned the first time a UA submits to a 
DBA object a schema retrieval request requiring cat- 
alog lookup for the specified database. Once estab- 
lished, the catalog server process remains in service 
for all DBA objects requiring access to the specified 

50 database. Each request constitutes a complete UOW, 
thereby ensuring serialization. 

Fig. 2 illustrates a preferred subcomponent 
structure for the system of Figure 1. For exemplary 
purposes. DBA object 14 of Fig. 1 is shown in more 

55 detail. Catalog service methods 30 are coupled to 
process 28 and SQL service methods 24 are coupled 
to process 26, as shown in Fig. 1. 

In Fig. 2, methods 24 and 30 each mode! a logical 
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connection between DBA object 14 and the underly- 
ing database management system (DBMS) coupled 
to database 01. For every request from a UA (not 
shown), DBA object 14 first checks to determine 
whether a logical connection to the appropriate ser- 
ver process exists and, if not, calls a connection man- 
ager object (not shown) to establish the necessary 
logical connection by spawning a new server process 
or incrementing the related connection count for an 
existing server process in a database connection ta- 
ble (DBCT). The connection manager is responsible 
for determining whether a server process can be 
shared or a new server process must be spawned. 
The connection manager manages a Database Con- 
nection Table (DBCT) in global shared memory, 
which stores information about all server processes. 
The connection manager and DBCT are discussed 
below in connection with Figs. 4-5. If the logical con- 
nection already exists. DBA object 14 sends the re- 
quest to the appropriate server process by way of an 
associated named pipe (managed by the interprocess 
communication service subcomponent) and waits for 
return messages providing the results of the request. 

The rules for selecting the server process and for 
synchronizing database access request message 
traffic are now discussed. For all schema retrieval re- 
quests, catalog server process 28 is selected. Cata- 
log server process 28 is shared across all instances 
of DBA objects referencing the same database name. 
Multiple requests to the same server process are ser- 
ialized by operation of the server's named pipe in a 
manner known in the art. In Fig. 2, the application pro- 
gram interface (API) 42 automatically performs the 
activities necessary to link to catalog server process 
28, API 42 accomplishes its assigned tasks through 
the interprocess communication (IPC) service sub- 
component 44. API 42 translates the database ac- 
cess requests received from the UA to create mes- 
sage packages to be passed by way of a named pipe 
(IPC 44-46) from methods 30 to process 28. Also, 
when messages are returned from process 28 to 
methods 30. API 42 creates the output objects for the 
UA using data returned in a global shared memory 
(Figs. 4-5). 

IPC 44-46 is responsible for passing data and 
messages between the client methods 30 and the 
catalog server process 28. IPC 44-46 creates and 
manages the necessary "named pipes". IPC objects 
44-46 receive a request packet from API 42 and then 
uses a named pipe to transfer this request packet to 
server process 28. which receives the request packet 
at the request manager (RM) 48. RM 48 processes 
the request packet and passes a response packet to 
IPC 46-44 for transfer through the named pip to API 
42. 

Named pipes are used because the processes 
represented by m thods 30 and process 28 are unre- 
lated. As is well-known in the art, a named pipe allows 



transfer of data between unrelated processes in a 
first-in-first-out (FIFO) fashion and also permits syn- 
chronization of process execution. Named pipes can 
remain permanently in the file system hierarchy and 
5 can be disconnected and reconnected to various 
processes by means of system file calls. Server proc- 
ess 28 creates the named pipe nrianaged by IPC 46- 
44. The named pipe is local and duplexed to allow bi- 
directional data flow. It also blocks read or write op- 
to erations in "wait" mode until data is available to be 
read or enough room is available for the data to be 
written. Other named pipe characteristics may be 
specified as inputs. 

Methods 30 in client object 14 send a request 
15 over the named pipe to server process 28, which 
processes the request and sends a response back. 
Server process 28 should then disconnect the named 
pipe, reconnect it and wait for the next request from 
object 14, In the case of the shared process 28, the 
20 named pipe is then disconnected from object 14 and 
reconnected to another DBA object requiring schema 
retrieval services. It is preferred that the client object 
14 send a disconnect request to server process 28 to 
notify server process 28 when it may disconnect the 
25 named pipe from methods 30. 

Similarly, SQL execution methods 24 in DBA ob- 
ject 14 communicate over a second named pipe to 
SQL server process 26 by way of API 50. client IPC 
52, server IPC 54 and request manager 56. Because 
30 SQL server process 26 is a "shared" server process, 
the second logical path between methods 24 and ser- 
ver process 26 operates substantially as described 
above in connection with the first logical path be- 
tween methods 30 and process 28. Specifically. 
35 when the second logical path can be shared, the 
named pipe (IPC 52-54) is disconnected and recon- 
nected among the associated DBA objects, remaining 
fully linked to shared SQL server process 26. How- 
ever, because the SQL UOW execution messages 
40 must be serialized, additional requirements are im- 
posed on API 50 as is now discussed. 

A SQL server is used for all SQL UOW execution 
requests from the client UA. Although an exclusive 
SQL server is generally desired because updates 
45 may have been made concurrently to the specified 
database and the UOW must associate only with the 
currently-used DBAobject, in some situations the UA 
client may intend only short transactions against the 
specified database and may beneficially employ 
50 many DBA object instances against the same data- 
base, such as shown for process B in Fig. 1 . For such 
applications, a shared SQL server exemplified by 
SQL server process 26 can be used subject to the fol- 
lowing restrictions. 
55 With a shared SQL server, all SQL requests must 

be made within a single transaction "scope". A trans- 
action scope is demarcated using two methods em- 
bedded in DBA object 14, such as a beginTransac- 
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tion() method and a endTransactionQ method. The 
beginTransactionO method internally obtains a mutu- 
ally exclusive (mutex) semaphore associated with 
shared SQL server process 26. This mutex sema- 
phore is owned by one requester at a time and, upon 
endTransaction(). the mutex semaphore is released, 
becoming available for new ownership. By requiring 
every UA that uses the shared SQL server to make 
the requests within a transaction scope marked by 
acquisition and release of a mutually exclusive sem- 
aphore, all database accesses are thus serialized 
within single UOW scope, thereby permitting the use 
of a shared SQL server process. 

When a DBA object is first created, the object 
constructor initializes the anchor block 58 and the 
DBCT 60. Fig. 4 shows data access anchor block 58 
and DBCT 60 residing In the global shared memory 
of the database processing system. Anchor block 58 
is named to permit access by other concurrent proc- 
esses. To protect the global data area from simulta- 
neous access, a mutex semaphore 62 Is used to ser- 
ialize access similarly to the above discussion in con- 
nection with Fig. 2. During Initialization, shared mem- 
ory is allocated for the global data area and mutex 
semaphore 62 is created. Anchor block 58 contains 
some global data and pointers to other data, such as 
larg database blocks moved to shared memory re- 
sponsive to database access requests. It also con- 
tains a mutex semaphore counter 64, a pointer 66 to 
DBCT 60, a pointer 68 to the DBCT memory pool, the 
SQLCA data 70 related to SQL errors, the system re- 
turn code (RC) 72 for system error, and the Internal 
return code (RC) 74 identifying system error type. 
Fields 70-74 are used to save Information about er- 
rors occurring during initialization of either the catalog 
or SQL server processes related to the client DBA ob- 
ject to which anchor block 58 is related. 

If a process dies during ownership of mutex sem- 
aphore 62, no other process has access to mutex 
s maphore 62 thereafter and a new semaphore name 
must be created. Counter 64 Is used together with a 
local process counter to handle the creation of new 
mutex semaphore names under such circumstances. 
The value held in counter 64 is part of the mutex sem- 
aphore name and, when a process attempts to use 
the mutex semaphore and finds the previous owner 
has died, a new name is generated in part by incre- 
menting counter 64 by one. When another process 
uses mutex semaphore 62, it then finds Its local coun- 
ter to differ from global counter 64 and responsively 
resets the local counter to quickly open the new mu- 
tex semaphore. 

Pointer 66 in Fig. 4 locates DBCT 60, which is the 
first such DBCT for the parent DBA object. When the 
connection manager (Fig. 5) determines that a new 
server process is required, the process is then 
spawned and is passed the following information 
when spawned: (a) the name of the database to which 



this server Is connected; (b) a pointer to the empty en- 
try (e.g. entry 76) in the DBCT to be filled out by this 
process after the spawning is successfully conclud- 
ed; and (c) semaphores used to communicate with 

5 the connection manager regarding errors. The con- 
nection manager Includes as an embedded subcom- 
ponent a request manager (RM) exemplified by RM 
56 in Fig. 2. The RM subcomponent sets the connec- 
tion entry In DBCT 60. exemplified by entry 76. dur- 

10 ing initialization of the server process and deletes en- 
try 76 during termination of the related server proc- 
ess. 

DBCT 60 keeps track of the database connec- 
tions. It contains information about the connected da- 

15 tabase and both catalog server processes and SQL 
server processes. Each entry, exemplified by entry 
76, preferably contains the name of the connected da- 
tabase, an identification entry for the connection, a 
usage count of the number of the associated DBA ob- 

20 jects sharing the corresponding server process, the 
corresponding server process type, the share mode 
(exclusive or shared) of the corresponding server 
process, a callable name for the corresponding ser- 
ver process, and a flag indicating whether the entry 

25 has been "deleted". 

It is useful at this stage to consider Fig. 3, which 
shows a data access process model that was consid- 
ered and rejected by the inventors of the present ap- 
plication. Each DBA object in process B operates 

30 through a single process B connection. Although the 
process model in Fig. 3 offers some performance 
gain because it requires only one connection per da- 
tabase, it neither permits multiple SQL statements 
within a transaction nor does it permit selection of a 

35 SQL server process within a SQL window. Another al- 
ternative for supporting multiple statements in a sin- 
gle UOW through a single database connection proc- 
ess per database is to assign UOW management ac- 
tivities to the database connection process itself. 

40 Such a database connection process would check the 
requests coming in and process only those associat- 
ed with a current unit of work, holding the ones that 
are associated with other transactions. Although con- 
sidered, this alternative was also rejected by the in- 

45 venters because of the enormous processing over- 
head required in the database connection process. 
Also, because the database connection process 
holds requests from all other clients until the current 
UOW Is committed, database access requests from 
50 other clients may wait excessively in such a scheme. 
Thus, the mutex semaphore, UOW blocking scheme 
as discussed above in connection with Figs. 2 and 4 
is preferred. 

Fig. 5 illustrates a plurality of objects linked to- 
55 gether in a data storage means of a database proc- 
essing system. A connection manager 78 is shown 
coupled to a DBCT 80, which records the connections 
and processes for each database, exemplified by da- 
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tabase 82 and each database access object, exempli- 
fied by DBA object 84. Exclusive SQLServer process- 
es such as process 85 are directly linked through a 
named pipe to the client DBA object 84. Shared SQL 
server processes, exemplified by process 86, are 
also coupled through named pipes, such as named 
pipe 88. to the client DBA object 90. Named pipe 88 
can be disconnected and connected between DBA 
objects 90 and 92, for instance. DBA objects 84, 90 
and 92 are all created responsive to data access re- 
quests from a single user application (UA) 94. All ser- 
ver processes, including schema retrieval (catalog 
server) processes, exemplified by process 96, are 
created responsive to database access requests 
from DBA objects such as object 92. Each server 
process, such as SQL server process 86, is coupled 
to the DBMS associated with the specified database. 
The database access server procedure can be under- 
stood with reference to Fig. 6. 

In Fig. 6, user application 94 sends database ac- 
cess requests including SQL UOW messages to DBA 
object 92. The second of the two internal connection 
methods in object 92 (SQL execution object 98) then 
selects and connects to SQL server process 86, 
which is spawned if necessary. Server process 86 
causes the construction of named pipe 88, which is 
called by name (linked) through method 98. Method 
98 passes messages through named pipe 88 to ser- 
ver process 86, which then independently sends mes- 
sages to the database management system (DBMS) 
100. DBMS 100 then moves data from database 102 
responsive to the messages from server process 86. 
Server process 86 causes data from DBMS 100 to be 
moved to a shared memory region 104. This avoids 
tying up named pipe 88 with long data flow transfers. 
Instead, server process 86 merely passes a shared- 
memory pointer back to DBA object 92. Finally, user 
application 94, using the shared memory pointer, con- 
nects to shared memory 104 by way of DBAobject 92 
and API object 1 06 and manipulates the data in accor- 
dance with the UOW being executed. 



Claims 

1. A method of operating a database processing 
system having a plurality of databases (82), a 
plurality of user applications (UAs) (94) for proc- 
essing database access requests including sche- 
ma queries and standard query language (SQL) 
units of work (UOWs), and a plurality of database 
access (DBA) objects (90, 92, 84) for passing 
messages between said UAs and said databas- 
es, said method providing acc ss to data in a first 
database responsive to one or more database ac- 
cess requests from a first UA, said method com- 
prising the steps of: 

sending a database access request from 
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the first UA to a first DBA object for passing mes- 
sages between said first UA and said first data- 
base, said first DBAobject including first schema 
retrieval methods and first SQL execution meth- 
5 ods; 

transferring schema query messages be- 
tween said first schema retrieval methods of said 
first DBA object and said first database through 
a first logical path; and 
io transferring SQL UOW execution messag- 

es between said first SQL execution methods of 
said first DBA object and said first database 
through a second logical path. 

15 2. The method of claim 1 wherein said first transfer- 
ring step comprises the steps of; 

if not already existent, spawning a first cat- 
alog server process (96) for retrieving data from 
said first database; and 

20 connecting said first DBA object to said 

first catalog server process. 

3. The method of claim 2 wherein said connecting 
step comprises the steps of; 

25 if not already existent, constructing a first 

named pipe object for transferring messages to 
and from said first catalog server process; and 

linking said first named pipe object to said 
first DBAobject. 

30 

4. The method of claim 3 wherein said first logical 
path is shared among a plurality of said DBA ob- 
jects by logically re-linking said first named pipe 
object to a DBA object responsive to a schema 

35 query message from that DBAobject. 

5. The method of claim 4, further comprising the 
steps of: 

if said first named pipe object is linked to 
40 a second DBA object, completing a schema 

query message transfer between said second 
DBAobject and said first database; and 

disconnecting said first named pipe object 
from said second DBA object. 

45 

6. The method of any preceding claim wherein said 
second transferring step comprises the steps of; 

if not already existent, spawning a first 
SQL server process (86) for executing UOWs in 
50 said first database; and 

connecting said first DBA object to said 
first SQL server process. 

7. The method of claim 6 wherein said connecting 
55 step comprises th steps of: 

if not already existent, constructing a sec- 
ond named pipe object (88) for transferring mes- 
sages to and from said first SQL server process; 
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and 

linking said second named pipe object to 
said first DBA object. 

8. The method of claim 7 wherein: 

said plurality of DBA objects includes a 
plurality of exclusive DBA objects and a plurality 
of associated DBA objects (90, 92); and 

said second logical path is shared among 
a plurality of said associated DBA objects by log- 
ically re-linking said second named pipe object to 
an associated DBA object responsive to a SQL 
UOW message from that associated DBA object. 

9. The method of claim 8 further comprising the 
steps of: 

if said second named pipe object is linked 
to a second DBA object, completing the transfer 
of a UOW execution message between said sec- 
ond DBA object and said first database; and 

disconnecting said second named pipe 
object from said second DBA object. 

10. The method of any preceding claim wherein said 
database processing system includes a plurality 
of said DBA objects coupled to a plurality of said 
databases through a plurality of said first and 
second logical paths; and at least one said sec- 
ond logical path is shared by a plurality of said 
DBA objects. 

11. A database processing system including a plural- 
ity of objects and a plurality of databases (82), 
said objects including a plurality of user applica- 
tions (UAs) (94) that make database access re- 
quests for processing schema queries and stan- 
dard query language (SQL) unit of work (UOW) 
executions, said system comprising: 

a plurality of database access (DBA) ob- 
jects (84. 90, 92) for receiving said database ac- 
cess requests for one database from one UAand 
having methods for exchanging schema retrieval 
messages with said one database over a first log- 
ical path and methods for exchanging SQL UOW 
execution messages with said one database over 
a second logical path; 

a plurality of catalog server processes 
(96), each linked to one database, for processing 
said schema queries responsive to messages ex- 
changed with said DBA objects; 

a plurality of SQL server processes (85, 
86), each linked to one database, for processing 
said SQL execution requests responsive to mes- 
sages exchanged with said DBA objects; and 

connection manager means (78) for se- 
lecting and linking a catalog server process to a 
DBA object to form a first logical path and for se- 
lecting and linking a SQL server process to a DBA 



object to form a second logical path. 

12. The system of claim 11, wherein each database 
is linked to one catalog server proc ss that is 

5 shared by all DBA objects linked tothatdatabase. 

13. The system of claim 11 or 12, wherein said plur- 
ality of DBA objects includes: 

associated DBA objects (90, 92), each 
10 having methods for exchanging said SQL UOW 

execution request messages with a SQL server 
process over a second logical path shared with 
other associated DBA objects; and 

exclusive DBA objects (84), each having 
15 methods for exchanging said SQL UOW execu- 

tion request messages with a SQL server proc- 
ess over an exclusive second logical path that is 
unavailable to other DBA objects. 

20 14. The system of claim 13 wherein said plurality of 
SQL server processes includes: 

one or more exclusive SQL server proc- 
esses (85) each linked to no more than one ex- 
clusive DBA object; and 

25 one or more shared SQL server processes 

(86), each available for linkage to any of a plural- 
ity of said associated DBA objects. 

15. The system of claim 14 wherein said connection 
30 manager means includes: 

exclusive link means for linking an exclu- 
sive SQL server process to one exclusive DBA 
object to form an exclusive second logical path; 

shared link means for linking a shared SQL 
35 server process to one associated DBA object to 

form another second logical path; and 

switching means for disconnecting a 
shared SQL server process from a first associat- 
ed DBA object and for re-linking said shared SQL 
40 server process to a second associated DBA ob- 

jecL 

16. The system of claim 15 wherein said switching 
means includes: 

45 database connection table (DBCT) means 

(80) for specifying the number of DBA objects 
shared by each said shared SQL server process. 



50 
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